home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / May 96 / Re ODF Container.1 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.4 KB  |  [TEXT/ttxt]
  1. Subject:     Re: ODF Container
  2. Sent:        5/28/96 2:56 PM
  3. Received:    5/28/96 3:12 PM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8.  
  9. Just one random comment. 
  10.  
  11. Don't forget that moving C++ code into a shared library means that all 
  12. clients of this shared library have to use the same version of the same 
  13. compiler. This is why we don't have the framework layer of ODF in a 
  14. shared library. Until we can move the whole framework to SOM using a 
  15. direct-to-SOM compiler this in not doable for us. We would have to ship 
  16. one shared library for every C++ compiler and even one for each version 
  17. of a given compiler. On the other hand it is totally doable for you to do 
  18. it if you decide to use only one compiler and you don't expect any client 
  19. other than yourself using your shared library. But, the best solution for 
  20. object oriented code in a shared library is to use SOM not C++. If you 
  21. look at the ODFLibrary it is only exporting C and SOM classes. 
  22.  
  23. >    I was very happy to discover that ODF R1 has a container part editor. I
  24. >was about to try to create something with its basic functionality, but you
  25. >have saved me, and many others, the trouble.
  26. >
  27. >   There is one aspect of ODFContainer, however, that bothers me. I am
  28. >attempting to convert a simulation into OpenDoc parts. The initial version
  29. >should have about a dozen parts that function quite closely to what is
  30. >already in ODFContainer. The problem is that each one of these parts will
  31. >end have a lot of code that is almost identical. As far as I can determine,
  32. >most of what is being done in the container framework classes is generic
  33. >and could be put into base classes. In fact, only the Part, Frame, and View
  34. >classes seem to contain features that require parts of them to be varied
  35. >from part to part.
  36. >
  37. >    What I would like to have is a basic container framework that has most
  38. >of its functionality in a shareable library, such as ODFLibrary. As in all
  39. >good object oriented code designs, only the minimum amount of nonredunant
  40. >code would have to be incorporated into each individual part. Since most of
  41. >the new parts that will be produced in the future as likely to be based on
  42. >ODFContainer, I would like to think that there is some way of reducing the
  43. >their size by putting the redundant code in a common library. This approach
  44. >would have the added bonus that most new users wil have a much easier time
  45. >trying to understand ODF if most of the remaining complexity can be hidden.
  46. >I would anticipate that new users will be able to create new parts in a
  47. >fraction of the time that it is now requires since they need only
  48. >concentrate on the portions that absolutely have to be modified. What would
  49. >also be nice, is a set of tutorials derived from this simple container
  50. >model.
  51. >
  52. >    I have made two different attempts to create such a container
  53. >framework, but both ended up crashing when I tried to use them. My question
  54. >is, then, whether this approach is viable at all. If someone with more ODF
  55. >experience can help me, please let me know.
  56. >
  57. >Doyle Rhynard
  58. >
  59.  
  60.  
  61. .......................................................................
  62.  Henri Lamiraux                                      lamiraux@apple.com
  63.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  64. .......................................................................
  65.  
  66.